home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3594 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: news.eunet.fi!fipnet!kone!jsaarinen
  2. Newsgroups: comp.sys.amiga.programmer
  3. X-NewsReader: IntuiNews 1.2b (31.7.94)
  4. References: <38232464@kone.fipnet.fi> <4ga21v$lsk@brachio.zrz.TU-Berlin.DE>
  5. From: "Jyrki Saarinen" <jsaarinen@kone.fipnet.fi>
  6. Date: Wed, 21 Feb 96 18:00:40 UT
  7. Comments: Illegal date header - new date added by quicknews
  8. X-Original-Date: Wed, 21 Feb 96 13:01:37 
  9. MIME-Version: 1.0
  10. Content-Type: text/plain; charset=iso-8859-1
  11. Content-Transfer-Encoding: binary
  12. Subject: Re: Texture/Gouraud innerloop speedtests
  13. Message-ID: <38232562@kone.fipnet.fi>
  14.  
  15.  
  16. > >Ok, I did a little research. My CPU is a 40MHz 68040,
  17. > >a Warp Engine with a very fast memory system, maybe
  18. > >this is the reason I did not gain any speed even if
  19. > >I turned the data cache and thus data burst off,
  20. > >with data burst everything was about 50% slower.
  21. > 
  22. > Not very surprising! Data burst means that whenever
  23. > a cache-miss occurs the CPU loads 4 longwords around
  24. > the mem area where the data to be fetched is. For a
  25. > tmapping loop this means that for almost any pixel that
  26. > is fetched from the texture the CPU keeps the bus busy
  27. > for 4 mem cycles!
  28.  
  29. ;) I said 50% slower when I switched the data cache OFF.
  30.  
  31. > >So the frame rates were for a 320x256 screen:
  32. > >Texture/Gouraud/Shading table, 64k aligned: ~43 fps
  33. > >Plain Texture, 64k aligned: ~67 fps
  34. > 
  35. > fps? Are these figures for the mere repetition (320*256 times)
  36. > of the innerloop?
  37.  
  38. Yep. 
  39.  
  40. > >    move.b    (a3,d0.l),d1
  41. > >    move.b    (a4,d1.l),(a0)+
  42. >         [...]
  43. > >    dbf    d7,poly
  44. > >    rts
  45. > 
  46. > If I understand your problem right you wonder why the
  47. > two version are almost equal in terms of speed? The scheduling
  48. > is not optimal in both versions, you use the data that you
  49. > fetch in the next instruction.
  50.  
  51. If you have read my posting .. I said I could not speed
  52. up the "normal index version" of the routine, I tried
  53. all the possible instruction combinations.
  54.  
  55. Besides, the 64k-aligned routine is ~20% faster. And it is
  56. properly scheduled at least on the 040, I could gain about
  57. ~10-15% by changing instructions to that order where
  58. they are now.
  59.  
  60. --                               _
  61. a Stellar programmer          _ //
  62. "Amiga - back for the future" \X/
  63.